1. Field of the Invention
The present invention relates generally to a communications infrastructure, and more particularly to a system and method for providing a routing service that enables distributed applications (clients) to locate service provider application (target services) in distributed computing environment.
2. Background of the Invention
A common characteristic of large enterprise applications is a horizontal data distribution in multiple instances of one application. For example, a telephone service provider may have a single customer record inquiry system that runs in each of its multiple mainframe regions. Each mainframe region has databases that contain information regarding a portion of the customers of the telephone service provider. For example, the Alabama mainframe region maintains databases regarding customers in Alabama; and the Georgia mainframe region, customers in Georgia. To obtain the information associated with a particular customer, a client or a distributed application that is requesting the information determines which mainframe region the information is located based on the NPA/NXX portion of the customer's telephone number. Thereafter, the distributed application communicates with the customer record inquiry system (the target) running on the mainframe for that region to obtain the information.
To provide interoperability between applications that may be written in different languages and/or run on different platforms in distributed computing environment, custom-programmed middleware solutions have been developed. Exemplary middleware solutions include distributed object systems such as CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Model), and EJB (Enterprise Java Beans). Among these solutions, CORBA has been the most popular packaged middleware solution because it supports detail transparency and interface standardization.
CORBA is OMG's (Object Management Group's) open, vendor-independent specification for an architecture and infrastructure that computer applications use to work together over networks. CORBA is designed to provide interoperability between applications that may be written in different languages and may run on different platforms. CORBA defines an implementation independent object model, which is built with a programming language, such as C++ or Java. CORBA provides object services that are domain-independent interfaces that are used by many distributed object programs.
CORBA defines an ORB (Object Request Broker) that handles the transport of information between applications. The ORB functions as a communications infrastructure, transparently relaying object requests across distributed heterogeneous computing environments. ORB simplifies distributed programming by decoupling the client from the details of the method invocations. Interoperability is accomplished through well-defined object interface specifications, which allow client applications to connect to the ORB, specified in OMG IDL (Interface Definition Language). OMG IDL defines the types of objects according to the operations that may be performed on them and the parameters to those operations.
FIG. 1 shows the basic CORBA ORB architecture. Client 100 is the entity that wishes to perform an operation on an object. The object, which is known as a “servant” and implemented by a server, is an entity that consists of an identity, an interface and an implementation. Object implementation 102 is a code and data that actually implements the object. Object implementation 102 provides the semantics of the object, usually by defining data for the object instance and code for the object's method. The objects export object references with interfaces specified by the OMG IDL for use by clients. The object reference contains an identification of the object implementation so that the object adapter can pass the client's request to the correct object in the server. The CORBA architecture is implemented in a conventional programming language, such as C, C++, Java, or Smalltalk.
To use CORBA, OMG IDL specification is written and compiled to generate client stubs and server skeletons in the languages in which client and server are written. The stubs and skeletons serve as proxies for clients and servers, respectively. The stubs and skeletons are then included in the client's program and the server's program, respectively. Thereafter, Client 100 initiates a request to an operation on object implementation 102 through IDL stub 106. The request is an event carrying information that includes an operation, an object reference of the service provider, and actual parameter. IDL stub 106 represents the mapping between the language of implementation of client 100 and ORB 104. IDL skeleton 110 represents the mapping between the language of implementation of object implementation 102 and ORB 104. ORB 104 locates the appropriate implementation code, transmits parameters and transfers control to object implementation 102 through IDL skeleton 110. In performing the request, the object implementation may obtain some services from ORB 104 through object adapter 112. When the request is complete, control and output values are returned to client 100.
One of many challenges in CORBA is to provide a high-level of management for the very large amount of underlying distributed objects. Most of the CORBA systems fail to provide better performance when dealing with large scale distributed application.